1. Field of the Invention
This invention relates generally to instruction implementation and register utilization within a computer processor, and more particularly to providing a method, article, and system for the effective implementation of translate-n-to-n instructions implemented on 24, 31, and 64-bit architectures, while maintaining backward compatibility with existing systems.
2. Description of the Related Art
Software has become a major portion of the cost associated with computer systems because it is very “labor-intensive.” Some of this cost is due to the effort involved in writing and debugging programs; other costs involve maintaining programs after they have been written. Accordingly, considerable effort has been expended in order to reduce the time and costs involved with writing, debugging and maintaining moderate and large software programs. Much of this effort has been related to developing programming languages and programming techniques, which will allow programmers to build on or “reuse” programs and code segments that have been written by others.
Until very recently, software programming was heavily dominated by an approach referred to as “structured programming.” Common software programming languages used in this approach were, and remain, BASIC, FORTRAN, COBOL, PL/1, and C. These are considered “higher order” languages that are written in human readable code and ultimately translated into machine or computer readable code by a compiler. Typically, structured programs have consisted of a combination of defined variables of specific data types, e.g. integer, real, and character, and a complimentary set of functions or routines, which operate on these variables. Often, a program would include sub-routines which are smaller routines within a program or larger routines that carry out certain operations, e.g. printing data in a given output format. The emphasis to this approach was inputs—functions—outputs and they were often represented as flowcharts by the designers, which logically represented how the program functioned and branched into different functional paths. As an increasing number of programs became large (tens of thousands of lines of code and above) structured programs became increasingly complex and difficult to write, troubleshoot and maintain.
In response to the unwieldy nature of structured programs and their related flowcharts, new approaches to software engineering called Object-Oriented Design (OOD) and Object-Oriented Programming (OOP) have emerged and gained increasing popularity among software developers. OOP promised greater reuse and maintainability than its structured programming predecessor because of an emphasis on well-defined and self-contained objects, rather than the structured programming emphasis on a proliferation of relatively loosely related data manipulating functions and subroutines.
Object Oriented Programming techniques involve the definition, creation, use and destruction of “objects.” These objects are software entities comprising data elements, or attributes, and methods, or functions, which manipulate the data elements. The attributes and related methods are treated by the software as an entity and can be created, used and destroyed as if they were a single item. Together, the attributes and methods enable objects to model virtually any real-world entity in terms of the entity's characteristics, represented by the data elements, and the entity's behavior, represented by data manipulation functions or methods. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs. Object-Oriented Programming languages include C++, Java, as well as other languages.
As was previously mentioned the “higher order” programming languages (structured, object oriented) must ultimately be translated into machine or computer readable code by a compiler to carry out instructions to be executed by a computing device and/or processor.
Instruction sets used in computer systems employing so-called Complex Instruction Set Computing (CISC) architecture include both simple instructions (e.g. LOAD, or ADD) and complex instructions (e.g. PROGRAM CALL, or LOAD ADDRESS SPACE PARAMETERS). Typical complex instruction-set computers have instructions that combine one or two basic operations (such as “add”, “multiply”, or “call subroutine”) with implicit instructions for accessing memory, incrementing registers upon use, or dereferencing locations stored in memory or registers. As an example to which the invention has particular relevance, see “The z/Architecture Principles of Operation” (Publication Number SA22-7831-04, available from IBM Corporation, Armonk, N.Y.), which is incorporated herein by reference in its entirety. As these computer systems (e.g. IBM System 390, IBM System z9) have become more powerful, larger percentages of the instruction set have been implemented using hardware execution units to increase system performance. Conventionally, the complex functions are implemented in microcode because building hardware execution units to execute them is expensive and error prone. A microcode/microprogram implements a central processing unit (CPU) instruction set. Just as a single high level language statement is compiled to a series of machine instructions (load, store, shift, etc), each machine instruction is in turn implemented by a series of microinstructions, sometimes called a microprogram.
The Extended-Translation Facility 2 (ETF2) is an instruction set introduced on the IBM series of z/900 processors. The z/900 processors are designed for use in high performance computer servers for data and transaction serving. The z/900 processors and associated computer servers are designed to support both 32 and 64 bit computations, as well as both structured and object oriented programming languages. The ETF2 performs operations on both single-byte and double-byte data. Single-byte data may be ASCII, EBCDIC, or other data that can be encoded in a single byte. The double-byte data may be Unicode data, which is data that uses binary codes of the Unicode Worldwide Character Standard and enables the use of characters of most of the worlds written languages. The facility consists of eleven instructions, which are documented in “z/Architecture Principles of Operation” (Publication Number SA22-7832-04, available from IBM Corporation, Armonk, N.Y.), which as previously stated is incorporated herein by reference in its entirety.
However certain ETF2 instructions, and in particular, the TRANSLATE ONE TO ONE, TRANSLATE ONE TO TWO, TRANSLATE TWO TO ONE, and TRANSLATE TWO TO TWO (hereafter referred to as translate-n-to-n instructions) have characteristics that make them particularly difficult to exploit in the Java environment.
Each of the translate-n-to-n instructions 600 (please see FIG. 6) is designed to translate the argument characters of a second operand 606 using a translation table 602 designated by general register 1 (GR1) 612. Translation proceeds until either a model-dependent number of characters have been processed or until the character selected from the translation table 602 matches a test character 616 specified in general register 0 (GR0) 614. Stopping on a test character 616 may be the expected result when translating text that has a predictable end character, for example a null, new-line, or carriage return. However, in certain environments such as Java, the test character may either be unpredictable or undefined. In such an environment, extra coding is required to establish a least-expected test character, manually translate if is it is encountered, and then resume translation following it.
In addition for TRANSLATE ONE TO ONE and TRANSLATE ONE TO TWO instructions, the translation table is defined as being doubleword aligned, which is a boundary that Java can easily accommodate. However, for TRANSLATE TWO TO ONE and TRANSLATE TWO TO TWO, the translation table is defined as being 4K-byte aligned. Java has no means of enforcing a 4K alignment on its users. In order to use the TRANSLATE TWO TO ONE or TRANSLATE TWO TO TWO instructions in Java, the system must copy the user-supplied translation table to a 4K-aligned temporary buffer and then execute the instruction. Copying a 64K or 128K translation table males the use of the instructions impractical in a Java environment.
The present invention is directed to addressing, or at least reducing, the effects of, one or more of the problems set forth above, through the introduction of an enhanced version of ETF2.